1. Field of the Invention
The present invention relates to the field of database management systems in general, and specifically, to the use of database management systems to support software applications offered in Software as a Service (SaaS) environments.
2. Description of the Background Art
In recent years, new models for computing and the delivery of software have developed. One such model is commonly referred to Software as a Service (SaaS). In SaaS, an application provider (or software vendor) develops a software application and hosts and operates the application for use by its customers over a network such as the Internet. Each customer (or tenant) perceives that they have a dedicated application and database just for them and their users, but in reality the same application and database can serve multiple tenants concurrently and isolate one tenant and their data from another. A tenant is a company or organization which contracts with an application provider to use the application provider's SaaS-enabled application. The tenant is the application provider's customer.
Typically, the tenants of the application do not install the application on their own computer equipment. Instead, the tenants buy a service or subscription from the application provider, and the tenants access the application remotely, often by means of a web browser or so called “thin-client’ interface. The application executes on a computer system which is typically deployed at a location separate from the tenant's premises or place of business such as the facility of the application provider or a third party hosting facility. In addition, one or more application components may be hosted at the tenant's premises to enable data extant at the tenant's equipment to be integrated with and accessed by the remotely hosted application. The tenant's multiple users access the application from one or more remote locations. The application provider typically provides this service to many different tenants at the same time. Use of the application is frequently offered under terms such as a monthly or weekly rental or at a fee based on the number of transactions or other operations executed rather than a perpetual license. When several or many tenants use the same application and associated database at the same time without being aware of each other, this arrangement is called multi-tenancy.
A problem with the existing art is that database systems are not designed to support storing data for multiple tenants in a single database. The prior art has attempted to solve this problem using a number of different data architectures for SaaS data storage. For example, a first approach is to use a separate database for each tenant. In this architecture, there is a separate database and database server for each tenant. All tenants can use the same application instance or customized versions. However, this is architecture suffers from a number of disadvantages including poor scalability, higher system resource and infrastructure requirements, inefficiency when the number of users per tenant is low, difficulty provisioning new tenants, and higher maintenance and administration costs (databases have to be backed up separately, schema's have to be kept in sync, and multiple servers have to be configured, monitored, started and stopped).
A second prior art approach uses a single shared database with separate schema and tables for each tenant. All tenants can use the same application instance or a customized version. The problem with this approach is that it is difficult to keep the separate schemas synchronized. Also, it is more difficult to back up and restore an individual tenant's data.
A third prior art approach is a single shared database with shared schema and shared tables for all tenants. Each row and index entry of each table has an additional non-unique key component that is a tenant identifier. All tenants use the same application instance. However, this third prior art approach also has a number of problems including: invasiveness to applications due to the new column required in every table, low security due to mixing of tenant data in tables and indexes, poor query performance due to the need to include a tenant identifier in every query and an increase in the required number of input/output operations, caused by a reduction in locality-of-reference because rows of a table may be physically intermixed among tenants, complexity of maintenance and archiving of an individual tenant's data, one tenant more likely to affect performance of another due to high coupling among tenants data and queries, lower reliability since an application error or index corruption can affect all tenants data, and lower availability since maintenance operations such as rebuilding an index affects all tenants.